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2 INTRODUCTION 


This document presents the IrDA Point and Shoot Application Profile. Section 3 describes the Point and 
Shoot Usage Model upon which the Application Profile is based. Section 4 presents the Point and Shoot 
Application Profile. 


2.1 References 


[IrLAP] 
(IrLMP] 


[IrPHY] 


[TTP] 


[LITE] 


[IrOBEX] 


[IirMC] 


[VCARD] 


[VCAL] 


[VNOTE] 


[VMSG] 


[TEXT] 


[PCL3] 
[PCL5] 
[PS] 

[ESCP] 


[EXIF] 


[FILE] 
[JETSEND] 
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3. POINT AND SHOOT (OBJECT PUSH) USAGE MODEL 


3.1 Introduction 


The IrDA Point and Shoot Usage Model is based on IrDA-Data that was initially defined and adopted in 
1994. It is recommended for high speed, short range, line of sight, point-to-point wireless data transfer 
and is targeted at the IrDA 1.1 Fast Infrared Data (FIR) 4 Mbps components. The model also applies to 
IrDA 1.0 Serial Infrared Data (SIR), and will be the same model for the recently announced IrDA Very 
Fast Infrared (VFIR). This model is useful to over 50 million electronic devices including desktop, 
notebook and palm computers, printers, digital cameras, public phones/kiosks, cellular phones, pagers and 
other mobile devices. 


3.2 Scope 


The scope of the information presented in this section is based on the ability to exchange data between 
two IrDA-enabled devices. The focus of this Usage Model is on the user’s experience. Many data 
exchange operations can be reduced to simple object push events, such as printing, faxing, business card 
exchange, image transfer, and file transfer. The Point and Shoot Usage Model is the universal way to move 
data objects between IrDA-enabled devices. The key to universal object exchange is support for standard 
object types (for example, vCard, JPEG (Exif), and text). Almost all IrDA devices will support this 
capability including PCs, printers, PDAs, cameras, phones, watches, pagers, storage devices, and kiosks. 
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3.3 User Scenario 
Many user scenarios are covered by Point and Shoot object push. The picture below captures the power 
and simplicity of this Usage Model. 
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In the following scenarios, the user can: 


e push a business card from his phone to another person’s PDA or PC. 

e pass the presentation stored on a PC to another PC. 

e print his business card from his watch. 

e fax a memo from his PDA. 

e store images or sound files on a portable storage device. 

e print or fax pictures directly from the storage device. 

e dial a pay phone simply by pushing a business card from his PDA. 

e — send pictures over the Internet by pushing pictures from his camera to a kiosk or a cell phone. 


The possibilities are endless and the user is control. 


3.4 Interoperability 


IrReady 2000 devices will have this Point and Shoot capability built-in. The use of standard object types 
will guarantee that objects are correctly understood on the other device. Devices will be able to alert the 
user when the other device will not understand an object being sent. 
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Below is a list of the different data types with examples of what the user may experience when pushing 
these objects from one device to another. This list is meant to be representative of the types of 
interoperable data exchange represented by the Point and Shoot Usage Model. This list is by no means 
exhaustive. 


3.4.1 Types of Data Exchange: 


> Business Cards (vCard) 
e Business Card Exchange 
e Phone List Exchange 
e Business Card Print 


> Appointments, To Do items, Alarms (vCalendar) 
e Calendar item exchange 
e Calendar item print 


> Text Notes (vNote) 
e =©Text item exchange 
e Text item print 


> Messages (vMessage) 
e Email message exchange 
e Email message print 


> Digital Images 
e Image exchange 
e Image print 


> Text Files 
e = Text file exchange 
e = Text file print 


> Generic Files 
e Exchange of files between file systems 


3.5 Usability 


Users will be able to transfer an object to another device by selecting the object and performing a simple 
operation (such as pressing a button). For example on a PC the user can send a file to another device by 
dragging the file and dropping it on an icon representing a remote device or an IR application. Another 
approach may be to select the object and perform a right mouse click operation that will bring up a menu. 
The user then selects the “send to IR” option and the object is sent. Sending your business card may be as 
simple as pushing a “send” button. 


The short-range, narrow angle of IrDA-Data allows the user to aim, in a Point and Shoot style, at the 
intended recipient. Close proximity to the other device is natural in this type of data exchange situation, as 
is pointing one device at another. The limited range and angle of IrDA-Data allows others to 
simultaneously perform a similar activity nearby without interference. The short-range and narrow angle 
of IrDA-Data provides a simple form of security and a natural ease of use. 


Other technologies with omni-directional capabilities are not as easy to use in this type of scenario. The 
user is not able to point at the intended recipient. Instead, the user must discover the other devices and 
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choose the appropriate recipient from a list. Close proximity to the intended recipient will usually not 
help, and choosing the proper device from a list may require special knowledge or additional information. 


Point and shoot object exchange using IrDA-Data is the simplest way to transfer objects between two 
devices. 


3.6 Configuration 


By default, no configuration should be required for pushing or receiving objects. In some systems the 
user can select the location of the inbox and perhaps the behavior of prompts. But the device must be 
equipped to Point and Shoot “out of the box.” In situations where some configuration is required, it 
should require minimal effort by the user, and should quickly and easily render the device ready to 
perform an object push or receive where appropriate. 


3.7 Reliability 


Objects will be sent error free. Specific reliability standards are identified in the test specifications 
associated with the required enabling technology. Those details are addressed in the Point and Shoot 
Application Profile (Section 4). 


3.8 Additional Information 


As objects are received, they may be put into an appropriate data store on the device or delivered to an 
appropriate application. For example, on a PC received business cards could be placed directly into the 
user’s PIM. These features may require some configuration on the part of the user. 
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4 POINT AND SHOOT PROFILE 


4.1 User Requirements 


4.1.1 Scope 


This Point and Shoot profile defines the minimum requirements for the protocols and procedures that 
shall be implemented in devices that support the Point and Shoot Usage Model. The most common 
devices implementing this Usage Model include PCs, notebooks, PDAs, mobile phones, printers and 
digital cameras. 


4.1.2 User Scenarios 


The basic scenario covered by this profile is an IrDA device pushing an object to another IrDA device (for 
example, a mobile phone pushing a business card to a PDA). 


4.1.3 Data Object Types 


It is necessary to define a set of standard object types for the Point and Shoot profile. The purpose of 
defining a standard set of data object types is to establish a baseline such that some level of 
interoperability can be reasonably achieved across a broad range of devices. This standard set of objects is 
NOT intended to span all of the possible data objects, nor is it intended to define a complete set of data 
objects to enable highly optimal application solutions. The intent is to define a minimal set of data objects 
which will establish a common denominator for specific classes of data types, so that interoperability 
between two devices will occur. 


Having a standard set of data objects does not preclude a device manufacturer from supporting other data 
objects which provide improved value to the end customer, or provide a more optimal end solution. 
Additional data objects may be supported, but generic interoperability must still be guaranteed in these 
circumstances in order to comply with the Point and Shoot profile. 


As an example, JPEG (Exif) is the default standardized data object for image data. This format is used to 
exchange image data on PCs, Digital Cameras, and other devices. Point and Shoot devices that need or 
require the support of sending or receiving image data should then support the processing of JPEG (Exif) 
files. It is entirely possible (and even probable) that future digital photography solutions will utilize new 
file formats for improved picture quality and/or efficiency. As these new file formats are developed, 
device manufacturers may include support of the new formats, but JPEG (Exif) support must still be the 
baseline requirement for interoperability. 


The standardized object types are shown in the table below. This table includes both required and optional 
object data types. Section 4.1.4 clarifies the types that are required for specific device capabilities. 
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Business Card 


Calendar items, 
Appointments, To do items, 
Alarms 


vCard [VCARD] 


vCalendar [VCAL] 


Business card exchange 
Phone list exchange 
Business card print 


Exchange of calendar items 
Calendar print 


Text Notes 


Messages and Emails 


vNote [VNOTE] 


vMessage [VMSG] 


Exchange text notes 
Text note print 
Email exchange 
Email print 


Text files 


Formatted Document Files* 


ASCII using CRLF [TEXT] 


PCL3 [PCL3] 
PCL5 [PCLS5] 


Exchange a text document 
Print a text document 
Print ready files 

Print driver output 


Postscript [PS] 
ESC/P-80 [ESCP] 
JPEG (Exif) [EXIF] 


Image exchange 
Image print 


Any [FILE] Generic file exchange 


*Note: These “Formatted Document Files” are never required to be supported by any device in order to 
comply with the Point and Shoot profile. However, they are the most common file types that printers are 
designed to handle. We include them here as a reference for devices that want to extend their 
functionality by supporting these types over IR. 


4.1.4 Device Capabilities 


The following sections discuss the specific capabilities and requirements of the various device classes. It 
is expected that additional categories will be added to this section over time. 


It is assumed that, unless explicitly mentioned in the sections that follow, IrReady Point and Shoot 
devices are capable of both sending and receiving objects. This means that both push clients and push 
servers are supported on these devices. It also means that the devices send and/or received objects in the 
ways described. 


Many devices are multi-functional, meaning that they have capabilities that span device categories. For a 
device to be compliant with the Point and Shoot Profile, it must comply with the capabilities described in 
all the relevant tables in this section. As an example, a device may function as both a PDA and a cell 
phone. In this case the device would need to comply with the capability requirements of both the PDA and 
cell phone tables from the following sections. 
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The following terms are defined for these sections. 


Required Mandatory support. Devices of this class must support this data type in the way 
described in order to be compliant with the Point and Shoot profile. 

Optional Optional support. The table suggests the way in which this must be done if 
supported, but devices of this class are not required to support this data type. 

Conditional Conditional support. If the device has an application that supports the particular data 


type, and has the capability to send and receive, it must send and/or receive this data 
type in the manner prescribed. 

Not Applicable | No support under most conditions. The particular data type makes little sense for the 
device class within the context of this profile. It should be noted that while support of 
the data type for this device class is not defined by this profile, it is not prohibited. 


The following discussion is intended to help clarify the motivation and usage of these terms. 


Requiring data types for a particular device class has the effect of prescribing a particular feature set for 
all devices of that class that wish to be compliant with the Point and Shoot profile. While some of these 
required data types are a natural outgrowth of the typical usage of these devices, others are not. For 
example, while it is natural for a digital camera to support the Image data type, it is not necessarily 
obvious (or inevitable) that a printer should support the Business Card data type. In either case, whenever a 
data type is required for a particular device class, it is done to enhance interoperability between devices in 
a natural and achievable way. 


Optional data types may, over time become required as device capabilities grow, and as the usage of 
IrReady devices becomes more common. There are currently a number of data types that are not required 
for device classes despite the fact that the usage would be natural and valuable for such a device. In these 
situations, vendors may add considerable value by implementing support for these data types. Over time, 
many of these optional data types will become required for certain device classes. 


Conditional support applies to device classes that support Point and Shoot, but whose specific 
complement of application support is not appropriately dictated by this profile. For example, cell phones 
have acommon set of possible applications (phone list, calendar, etc.), and will beam these data objects 
according to the Point and Shoot profile. However, it is not appropriate to say that all cell phones must 
support a phone list (or a calendar) application to be compliant with this profile. However, it is essential 
that these devices behave consistently. In other words, if they have the capability to push objects, then 
they must do so for all the defined applications that they support. In addition, these devices must support 
at least one of the data types defined as Conditional in the capability table for that device. 
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4.1.4.1 LAPTOPS AND DESKTOPS 


It should be noted that since Laptops and Desktops are required to support generic files, all of the other 
data types can conceivably be sent and received if treated as generic files. The purpose of the optional 
entries in this table is to outline appropriate behavior that brings a more meaningful experience to the user 
where possible. For example, if a desktop has an application (such as Outlook or Palm Desktop) that 
maintains a default phone list, support of the Business Card data type requires that the user be provided an 
interface from within the phone list application for sending and receiving Business Cards. It is not 
sufficient to import and export these data objects from the application and then send and receive them as 
generic files. 


Support Expected Appropriate Usage 


Business Optional Push Server: Business Card is stored into the database of the default 
Card PIM. 


Push Client: User interface is provided to select and send Business 
Card from within the PIM application. 


Calendar Optional Push Server: Calendar Item is stored into the database of the default 
Item calendar or scheduling application. 


Push Client: User interface is provided to select and send Calendar 
Item from within the calendar or scheduling application. 


Text Note Optional Push Server: Text Note is stored into the database of the default 
PIM. 


Push Client: User interface is provided to select and send Text Note 
form within the PIM application. 

Message Optional Push Server: Message is stored as an email in the default email 
application. 


Push Client: User interface is provided to select and send Message 
from within the email application. 


ASCII Text | Optional Push Server: Received object is stored as an ASCII Text file. 


Push Client: User interface is provided to select and send an ASCII 
Text file. 

Formatted | Optional Push Server: Received objects are stored as files. 

Document 


File Push Client: User interface is provided to select and send formatted 


document files from the file system. 
Image Optional Push Server: Images are received by default image manipulation 
application. 


Push Client: User interface is provided to select and send Images 
from the default image manipulation application. 


Required Push Server: Received object is stored as a file in the file system. 


Push Client: User interface is provided to select and send any file 
from the file system. 
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4.1.4.2. GENERAL FUNCTION PRINTERS 


Since Printers are receive-only devices, they are only required to support Push Server. 


Business 
Card 


Support 
Required 


Expected Appropriate Usage 


Push Server: Received Business Card is printed in a form that is 
reasonably understandable to the user. 


Calendar 
Item 


Required 


Push Server: Received Calendar Item is printed in a form that is 
reasonably understandable to the user. 


Text Note 


Optional 


Push Server: Received Text Note is printed in a form that is 
reasonably understandable to the user. 


Message 


Optional 


Push Server: Received Message is printed in a form that is 
reasonably understandable to the user. 


ASCII Text 


Formatted 
Document 
File 


Required 
Optional 


Push Server: Received text file is printed to the page as text. 


Push Server: Received document files are printed according the 
specifications for the particular document format. 


Image 


Required 


Push Server: Received Image object is printed to the page in a form 


that is reasonably understandable to the user. 


File 


Not Applicable 


Infrared Data Association 


None 
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4.1.4.3. PHOTO PRINTERS 


Since Printers are receive-only devices, they are only required to support Push Server. 


Support Expected Appropriate Usage 


Business Optional Push Server: Received Business Card is printed in a form that is 
Card reasonably understandable to the user. 


Calendar Optional Push Server: Received Calendar Item is printed in a form that is 
Item reasonably understandable to the user. 


Text Note Optional Push Server: Received Text Note is printed in a form that is 
reasonably understandable to the user. 


Message Optional Push Server: Received Message is printed in a form that is 
reasonably understandable to the user. 


ASCII Text | Optional Push Server: Received text file is printed to the page as text. 


Formatted | Optional Push Server: Received document files are printed according the 


Document specifications for the particular document format. 
File 


Image Required Push Server: Received Image object is printed to the page in a form 
that is reasonably understandable to the user. 


File Not Applicable | None 


Infrared Data Association 
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4.1.4.4 LABEL OR ADDRESS PRINTERS 


Since Printers are receive-only devices, they are only required to support Push Server. 


Business 
Card 


Support 
Required 


Expected Appropriate Usage 


Push Server: Received Business Card is printed in a form that is 
reasonably understandable to the user. 


Calendar 
Item 


Optional 


Push Server: Received Calendar Item is printed in a form that is 
reasonably understandable to the user. 


Text Note 


Optional 


Push Server: Received Text Note is printed in a form that is 
reasonably understandable to the user. 


Message 


Optional 


Push Server: Received Message is printed in a form that is 
reasonably understandable to the user. 


ASCII Text 


Formatted 
Document 
File 


Optional 
Optional 


Push Server: Received text file is printed to the page as text. 


Push Server: Received document files are printed according the 
specifications for the particular document format. 


Image 


Optional 


Push Server: Received Image object is printed to the page in a form 
that is reasonable understandable to the user. 


File 


Not Applicable 


Infrared Data Association 


None 
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4.1.4.5 DIGITAL CAMERAS 


Business 
Card 


Calendar 
Item 


Support 
Optional 


Optional 


Expected Appropriate Usage 
Push Server: Digital camera receives and stores Business Card. 


Push Client: User interface is provided to select and send Business 
Card. 


Push Server: Digital camera receives and stores Calendar Item. 


Push Client: User interface is provided to select and send Calendar 
Item. 


Text Note 


Message 


Optional 


Optional 


Push Server: Digital camera receives and stores Text Note. 


Push Client: User interface is provided to select and send Text Note. 
Push Server: Digital camera receives and stores Message. 


Push Client: User interface is provided to select and send Message. 


ASCII Text 


Formatted 
Document 
File 


Optional 


Optional 


Push Server: Digital camera receives and stores Text file. 


Push Client: User interface is provided to select and send Text file. 
Push Server: Digital camera receives and stores Formatted 
Document File. 


Push Client: User interface is provided to select and send Formatted 
Document File. 


Image 


Required 


Not Applicable 


Infrared Data Association 


Push Server: Digital camera receives and stores Image. 


Push Client: User interface is provided to select and send Image. 
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4.1.4.6 PDAs 


Business 
Card 


Support 
Required 


Required 


Expected Appropriate Usage 
Push Server: Business Card is stored into the phone list. 


Push Client: User interface is provided to select and send Business 
Card from the phone list. 


Push Server: Calendar Item is stored into the default calendar 
application. 


Push Client: User interface is provided to select and send Calendar 
Item from the calendar application. 


Text Note 


Message 


Optional 


Optional 


Push Server: Text Note is stored into the note list. 


Push Client: User interface is provided to select and send Text Note 
from the note list. 
Push Server: Message is stored into the email application. 


Push Client: User interface is provided to select and send Message 
from the email application. 


ASCII Text 


Formatted 
Document 
File 


Required 


Optional 


Push Server: Received object is stored in the collection of text 
files. 


Push Client: User interface is provided to select and send text files. 
Push Server: Formatted Document File is stored. 


Push Client: User interface is provided to select and send Formatted 
Document File. 


Image 


Infrared Data Association 


Optional 


Optional 


Push Server: Received object is stored in collection of Images. 
Push Client: User interface is provided to select and send Images. 
Push Server: Received object is stored in file system. 


Push Client: User interface is provided to select and send files from 
the file system. 
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4.1.4.7 CELL PHONES 


Business 
Card 


Support 


Conditional 


Conditional 


Expected Appropriate Usage 
Push Server: Received object is stored in the phone list. 


Push Client: User interface is provided to select and send Business 
Card from phone list. 


Push Server: Received object is stored in the calendar. 


Push Client: User interface is provided to select and send calendar 
items. 


Text Note 


Message 


Optional 


Conditional 


Push Server: Received object is stored in collection of Text Notes. 


Push Client: User interface is provided to select and send Text 
Notes. 

Push Server: Received object is stored in the collection of email 
messages. 


Push Client: User interface is provided to select and send email 
messages. 


ASCII Text 


Formatted 
Document 
File 


Optional 


Optional 


Push Server: Received object is stored as a text file. 


Push Client: User interface is provided to select and send text file. 
Push Server: Formatted Document File is stored. 


Push Client: User interface is provided to select and send Formatted 
Document File. 


Image 


Optional 


Not Applicable 


Infrared Data Association 


Push Server: Received object is stored in collection of images. 


Push Client: User interface is provided to select and send Images. 
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4.1.4.8 PAGERS 


Business 
Card 


Support 


Conditional 


Conditional 


Expected Appropriate Usage 
Push Server: Received object is stored in the phone list. 


Push Client: User interface is provided to select and send Business 
Card from phone list. 


Push Server: Received object is stored in the calendar. 


Push Client: User interface is provided to select and send calendar 
items. 


Text Note 


Message 


Conditional 


Conditional 


Push Server: Received object is stored in collection of Text Notes. 


Push Client: User interface is provided to select and send Text 
Notes. 

Push Server: Received object is stored in the collection of email 
messages. 


Push Client: User interface is provided to select and send email 
messages. 


ASCII Text 


Formatted 
Document 
File 


Conditional 


Optional 


Push Server: Received object is stored as a text file. 


Push Client: User interface is provided to select and send text file. 
Push Server: Formatted Document File is stored. 


Push Client: User interface is provided to select and send Formatted 
Document File. 


Image 


Optional 


Not Applicable 


Infrared Data Association 


Push Server: Received object is stored in collection of images. 


Push Client: User interface is provided to select and send Images. 
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4.1.4.9 HANDHELD SCANNERS 


Support Expected Appropriate Usage 


Business Optional Push Server: Business Card is stored. 


d : i P ; 
ou Push Client: User interface is provided to select and send Business 


Card. 


Calendar Optional Push Server: Calendar Item is stored. 


It 
ae Push Client: User interface is provided to select and send Calendar 


Item. 


Text Note Optional Push Server: Text Note is stored. 


Push Client: User interface is provided to select and send Text Note. 
Message Optional Push Server: Message is stored. 


Push Client: User interface is provided to select and send Message. 


ASCII Text | Optional Push Server: Text file is stored. 


Push Client: User interface is provided to select and send text file. 
Formatted | Optional Push Server: Formatted Document File is stored. 

Document 
File 


Push Client: User interface is provided to select and send Formatted 
Document File. 
Image Required Push Server: Scanner receives and stores Image. 


Push Client: User interface is provided to select and send Image. 


Not Applicable 


4.2 Profile Overview 


4.2.1 Configuration and Roles 


The following roles are defined for this profile. 


Push Server — The device that provides an object exchange server. The Push Server waits passively for 
the client to initiate the operation. 


Push Client — The device that pushes the object to the Push Server. The Push Client initiates the 
operation. 


The figure below shows an example of a Push between two mobile phones. In this example the phone on 
the left is a Push Client that pushes the object, and the phone on the right is a Push Server that receives the 
object. 
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Push Client Push Server 


4.2.2 Protocol Stack 


The diagram below defines the minimum required protocol stack that shall be implemented by a device 
that conforms to this profile. Alternative stacks or components (such as JetSend [JETSEND]) may be 
implemented by a device in addition to this minimum. 


Application Push 
Client 


Push Client Side Push Server Side 


IrDA Hardware is governed by the physical specification in [IrPHY]. 
IrLAP is the link level protocol specified in [IrLAP]. 

IrLMP is a multiplexing layer specified in [IrLMP]. 

Tiny TP provides flow control and is specified in [TTP]. 

IAS is the Information Access Service specified in [IrLMP]. 


OBEX includes both a session level protocol and an application framework. Both are specified in 
[IrOBEX]. 


Application Push Client and Application Push Server are the application entities, which provide the 
user interface and perform the operation of the Point and Shoot profile. They are discussed later in this 
document. 
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Ultra is not required for the Point and Shoot Profile. However, while not required, support is strongly 
encouraged in order to extend the interoperable reach of Point and Shoot devices [ULTRA]. 


4.2.3 Conformance 


For a device to conform to this profile, all capabilities indicated as mandatory shall be supported in the 
specified manner. This also applies to all optional and conditional capabilities for which support is 
indicated. All supported capabilities are subject to verification as part of the IrReady 2000 certification 
program. 


4.3 User Interface Aspects 


4.3.1 Mode Selection 


Push Server Mode is the state in which a Push Server is ready to receive an object from a Push Client. 
When entering this mode the Push Server must register the OBEX IAS entry and set the OBEX hint bit. It 
must be in a state where it is ready to respond to incoming Discovery frames and accept an incoming 
OBEX connection. 


It is ideal that a Push Server be in this mode whenever the physical IR port is enabled (in other words, 
when the IR port is able to receive signals). In some devices the IR port is enabled whenever the device is 
turned on. For other devices the user must explicitly turn on the IR port. Turning on the IR port will 
ideally correspond to entering Push Server Mode. 


However, it should be noted that for some devices it is either impractical or impossible to require that 
enabling the IR port will necessarily place the device into Push Server Mode. Where that ideal is not 
achievable, the user should be able to place the device into Push Server Mode as easily as possible, which 
is defined here as requiring only a single additional action on the part of the user. 


To summarize, there are two scenarios in which a device will enter Push Server Mode: 


Scenario One: The device automatically enters Push Server Mode when turned on. This is the 
recommended method. 


Scenario Two: The device enters Push Server Mode when the user specifically enables it. This method 
may be required for devices with security or power usage constraints. The user should only be required to 
perform a single action via the user interface to cause the device to enter Push Server Mode. 


4.3.2 Function Selection 


The Object Push Function initiates the sending of an object to a Push Server. The user initiates this 
function. Typically, the function is selected for a specific object or group of objects. For example, in the 
Windows environment the user selects a file in the Explorer window, clicks the right mouse button and 
selects “IR recipient” from the “Send to” menu. When the selection is made the object is sent. 


In most cases only one device will be available. The Point and Shoot Usage Model works best when the 
user selects the desired device by pointing at it. If multiple devices are in the IR space then the user must 
select from a list or be told to position the device so only one device is in range. The device may also use 
the hint bits of the discovered devices to identify those that support IrOBEX (since all Point and Shoot 
devices would support this hint bit). In this way a device could either present a more effective list to the 
user, or intelligently determine which of the devices is the most appropriate one to connect to. 
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4.3.3. Application Usage 


When the user wants to push an object from a Push Client to a Push Server, the following is a typical 
scenario. 


Push Client Push Server 


The user sets the device into Push 
Server Mode if it is not already. 


The user of the Push Client selects 
the object or objects to send. 


The user points the IR port of the 
Push Client device at the IR port of 
the Push Server device. 


The user selects the Object Push 
Function to send the selected 
object(s). (Objects being pushed 
should be of a type appropriate for 
the Push Server.) 


It is recommended that a status 
indicator show the progress of the 
operation. 


It is recommended that user 
intervention be kept to a minimum on 
the Server device. It is possible that 
the user may be asked to accept or 
reject the object. Also if an object with 
the same name already exists the 
user may be asked if the existing 
object should be overwritten. 


It is recommended that the user be It is recommended that, where 

notified of the result of the operation. | appropriate, the Push Server device 
notify its user of the result of the 
operation. 


4.4 Application Layer 


4.4.1 Feature Overview 


A device following the Point and Shoot profile must be a Push Client, a Push Server or both and must 
support appropriate content types from those listed in the next section. 


4.4.2 Content Types 


To achieve application level interoperability, content formats are defined for Object Push. Sections 4.1.3 
and 4.1.4 identify required and optional data types for Point and Shoot devices. If a device supports 
additional content formats for a given application, it must still support the required ones listed in these 
sections. 
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4.4.3 Generic File Push 


Generic File transfer applications can send and receive files in any format. It is assumed that in this case 
both devices contain applications that understand the file format or that the file is simply stored on the 
device. It is also possible to send directory hierarchies containing Generic Files. Push Servers are not 
required to support Generic Files and if they do support them they are not required to support 
folder/directory hierarchies. The Push Client must verify that the Push Server supports folder/directory 
hierarchies by attempting to set the current folder of the receiving device to the root folder (see Section 
4.5.5 for more details). 


4.4.4 Application Architecture 


The Push Client and Push Server are both built on top of the OBEX application framework. A Push Client 
uses OBEX to push objects to the inbox of a Push Server. The Push Client only knows that the objects are 
successfully received. It does not know the layout or construction of the Push Server’s inbox. 


A Push Server’s inbox must take one of the following forms: 


General Storage Location Holds objects of any type. 
An example is a directory in a file system. It is possible to 
automatically dispatch objects from a general storage location to a 
database. For example, if a vCard is received it can be dispatched to 
the address book. The exception is when pushing a folder hierarchy. 
For example, vCards that are inside a folder being pushed are not 
automatically dispatched to the address book. 

Database A data store or application that contains objects of a specific 
type. 
An example is an address book in a mobile phone, which holds 
phone book items (vCards). 

Process An application or program that processes the object as data. 
An example is a printer, which will print the object. Processes are 
allowed to process the object as it is received. This means that the 
object does not have to be completely received before processing 
can begin. Since OBEX uses Tiny TP flow control the Push Server 
can properly pace the Push Client. 


The table below shows the application procedure required by the Push Client for pushing one or more 
objects to a push server. 


Push Client Details 


OBEX CONNECT Target Header must not be used. 


One or more OBEX PUTs for sending one 
or more objects. 


OBEX DISCONNECT 


The following table shows the application procedure required by the Push Client for pushing a folder 
hierarchy to a Push Server. This procedure is optional. 
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Push Client Details 


Set the current folder to the root Name header is empty. 


using the SETPATH command. If 
this operation fails, 


then the Push Server does not 
support folders. 


Create a new folder (if it does not Name header is set to the name of the new folder. 


already exist) in the Push Server's 
current folder using SETPATH. The 
current folder is changed to this new 
folder. 


Push all files to the new folder using The Name header is set to the name of the file. 


a PUT command for each file. 


Folders are created using Name header is set to folder name. This 
SETPATH. application procedure is applied recursively to 
each folder until the folder hierarchy is sent. 
Setting the current folder to the root is only 
performed once at the beginning. 

Set the current folder back to the The Backup flag is set and no Name header is 


parent folder using SETPATH. sent. 


4.5 OBEX Requirements 


This section details the use of ITYOBEX in the Point and Shoot Profile. 


4.5.1 Symbols and Conventions 


The Application Profile must use the following scheme to define the support for individual features. The 
following symbols are used: 


Mandatory support. Refers to capabilities that shall be used in the profile. 

Optional support. Refers to capabilities that can be used in the profile, but are not required. 
x Excluded. Refers to capabilities that may be supported by the device but shall not be used in 

this profile. 


Some excluded capabilities are capabilities that, according to the relevant IrDA specification, are 
mandatory. These are features that may degrade operation of devices following this profile. Therefore, 
these features shall never be activated while a device is operating as a device within this profile. 
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4.5.2 OBEX Operations 


The table below shows the OBEX operations that are used in the Point and Shoot profile. 


OBEX Operation Push Client Push Server 


Connect 
Disconnect 
Put 

Get 

Set Path 
Abort 


Reserved 


x KX =O xXx FO € 
< Bae = GOn X< Bes = ES 


User Definable 
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4.5.3 OBEX Headers 
The table below shows the OBEX headers used in the Point and Shoot profile. 


OBEX Headers Push Client Push Server 


Count 

Name 

Type 

Length 

Time 
Description 
Target 

HTTP 

Body 

End of Body 
Who 
Connection ID 


Application Parameters 


Authenticate Challenge 


Authenticate Response 
Object Class 


Reserved 


< a < ba < be < Bea = Bae O Ba O B@n OC On = FO 
<x eal < ba < Be =< Bee = Bee O Be O BOs O FOr = FC 


User Definable 


4.5.4 Establishing an OBEX session 


Setting up an OBEX session for Point and Shoot involves three steps: 

1. Push Client discovers the Push Server device. 

2. Push Client establishes a Tiny TP connection to the Push Server device. (See Section 4.6, Tiny 
TP/IrLMP Operations.) 


3. Push Client performs an OBEX connect operation to the Push Server. 


The figure below shows how the OBEX session is established. 
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Client 


Server 


Client has discovered the 
Server. 


Client has established a Tiny 
TP connection to the server. 


F: 
OBEX session is established if 
the response includes the 0xA0 
(Success, final bit set) response 


The OBEX connection is established to the inbox service so no targeting information is used. The OBEX 
connect request must contain the following fields. 


Field/ 
Header 


Name Value Explanation 


Field 
Field 
Field 
Field 
Field 


Opcode for CONNECT 0x80 

Packet Length Varies 
OBEX Version Number Varies 
Flags Varies 


Max OBEX Packet Length | Varies 


The OBEX connect response must contain the following fields. 


Field/ 
Header 


Field 


Field 
Field 
Field 
Field 


Name Value | M/O Explanation 
Response code for Ox0OA |M OxA0 for success 
CONNECT request 

Packet Length Varies | M 

OBEX Version Number Varies | M 

Flags Varies | M 

Max OBEX Packet Length | Varies | M 
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4.5.5 Pushing Objects 


Objects are pushed to the Push Server using the OBEX PUT operation. Pushing an object can take one or 
more OBEX packets. Compliant OBEX Push Servers should be able to receive multiple sequential PUT 


requests. 


The PUT packet must include the following fields and headers. 


Field/ 
Header 


Name 


Explanation 


Field 


Opcode for PUT 


Field Packet Length Varies 


Header | Name Varies 


Header Varies 


Type 


Header | Length Varies 


Header | Body/End of Body | Varies 


0x02 is used for packets previous to the 
last put packet. 


0x82 (which is 0x02 with the high bit 
set) is used for the last put packet. 


The header value is the name of a 
single object, object store, or log 
information. 

The MIME type of the object. This 
header is optional but highly 
recommended. 

Length of the object. This header is 
optional but highly recommended. 

End of Body identifies the last chunk of 
the object body. 


The response to the PUT request has the following fields and headers. 


Field/ Name Value 
Header 
Field Response code | 0x90, 
for PUT OxAO, 
OxCD or 
OxCF 
Field Packet Length Varies 


M/O 


Explanation 


0x90 for continue 

OxAO for success 

OxCD if the object is too large 

OxCF if the object type is not supported 


Other headers, which can be optionally used, are found in [TrOBEX]. 


The type of an object is distinguished in two ways, first by using an extension in the name and second by 
sending a Type header. Sending a Type header is optional but highly recommended. Sending a Name 
header is mandatory. The table below shows the MIME types and name extensions required for each of the 


content types. 
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Object MIME encoding (Type) Name extension 


vCard 2.1 text/x-vceard .vef 


vCalendar 1.0 | text/x-vcalendar .VCS 
vNote 1.1 | text/x-vnote .vnt 
vMessage 1.1 | text/x-vmessage .vmg 
Plain ASCII text | text/plain xt 
PCL3 and PCL5 application/vnd.hp-pcl .pcl 
Postscript application/postscript .ps 


ESC/P-80 
JPEG (Exif) Image 


application/octet-stream 


Image/jpeg 


4.5.6 Folder Operations 


4.5.6.1 SETTING THE CURRENT FOLDER TO THE ROOT 


Setting the current folder to the root requires the SETPATH operation. The SETPATH request must 
include the following fields and headers. 


Field/ Name Value M/O Explanation 

Header 

Field Opcode for 0x82 M 

SETPATH 

Field Packet Length Varies | M 

Field Flags 0x02 M “Backup level” flag is set to 0 and “Don't 
Create” flag is set to 1 

Field Constants 0x00 M eae are not used and must be set 

Header liane Empty | M Name header is empty 


Field/ Name Value M/O Explanation 
Header 
Field Response code | 0xA0, M OxA0 for success — 
for SETPATH OxC3 or OxC3 if SETPATH is not supported 
OxD1 OxD1 if folders in the inbox are not 
supported 
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Field Packet Length 


Varies 


4.5.6.2 CREATING A FOLDER 
Creating a new folder requires the SETPATH operation. The SETPATH request must include the 


following fields and headers. 


Field/ Name 
Header 


Field Opcode for 
SETPATH 


Field Packet Length 


Field Flags 


Field Constants 


Header | Name 


Value 


0x82 


Varies 


0x00 


0x00 


Varies 


M/O Explanation 


M 

M 

M “Backup level” flag is set to 0 and “Don't 
Create” flag is set to 0 

M Constants are not used and must be set 
to 0 

M Name of the folder 


Name 


Explanation 


for SETPATH 


Response code 


Packet Length 


OxA0 or 
OxCD 


Varies 


OxAO for success 
OxCD if there is not enough room for a 
new folder 


4.5.6.3. SETTING THE CURRENT FOLDER BACK TO THE PARENT 


Setting the current folder back to the parent folder requires the SETPATH operation. The SETPATH 
request must include the following fields and headers. 


Field/ Name 
Header 


Field Opcode for 
SETPATH 


Field Packet Length 
Field Flags 


Field Constants 


Value 


0x82 


Varies 


0x03 


0x00 


M/O Explanation 


M 

M 

M “Backup level” flag is set to 1 and “Don't 
Create” flag is set to 1 

M Constants are not used and must be set 


to 0 
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Response to the SETPATH request for setting the current folder back to the parent has the following 
fields. 


Name Value Explanation 


Response code | OxA0 or OxA0 for success or OxC4 if the current 
for SETPATH OxC4 folder is the root. 


Packet Length Varies 


4.5.7 Disconnecting an OBEX session 


An OBEX session can be disconnected in two ways. First, the OBEX connection can be disconnected 
using the DISCONNECT procedure. Second, the underlying Tiny TP connection can be disconnected. 
Normally after all objects have been pushed, the Tiny TP connection to the OBEX server is disconnected 
so there is really no need to perform an OBEX DISCONNECT procedure. If the Tiny TP connection is 
used for other purposes as well (such as synchronization or file transfer) then the Tiny TP connection 
must be left up and an OBEX DISCONNECT should be issued. Push Servers must be able to handle both 
methods of disconnect. 


The OBEX DISCONNECT request must contain the following fields. 


Field/ Name Value | M/O Explanation 
Header 


Field Opcode for DISCONNECT | 0x81 M 
Field Packet Length Varies | M 


Other headers (such as Description) which can be optionally used are found in [IrOBEX]. 


The response to an OBEX DISCONNECT request must contain the following fields. 


Field/ Name Explanation 
Header 


OxAO OxA0 for success 


Field Response code for 
DISCONNECT 


Field Packet Length Varies 


4.6 Tiny TP/IrLMP Requirements 
This section details the use of Tiny TP and IrLMP in the Point and Shoot Profile. 


4.6.1 Tiny TP/IrLMP Operations 


Tiny TP and IrLMP combine to form the IrDA transport layer. The steps involved in setting up a Tiny TP 
connection to a Push Server are as follows: 
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1. Push Client discovers the Push Server device and establishes an IrLAP connection. 

2. Push Client queries the IAS of the Push Server for the LSAP-SEL entry of the OBEX IAS entry (see 
Section 4.7 IAS for more details). 

3. Push Client performs a Tiny TP connect request to the LSAP-SEL retrieved in step 2. 


If the Push Client already has an IrLAP connection to the Push Server then step | can be skipped and the 
Push Client should start at step 2. 


For the purposes of this Profile, a Point and Shoot device is not expected to be capable of sending and 
receiving simultaneously. However, a Point and Shoot device is expected to handle such a request from 
another device without dropping the connection. 


Note: If the Push Client has Push Server capability and there is already a Tiny TP connection to the Push 
Server of the Push Client device, then there may be problems if the Push Client attempts to establish a 
Tiny TP connection to the Push Server device. The reason is because the Push Server device may be built 
using IrDA Lite [LITE]. IrDA Lite does not require support of Tiny TP/IrLMP disconnect and some IrDA 
Lite devices may only allow one Tiny TP connection to OBEX at a time. This means that these devices 
cannot support two Tiny TP connections to OBEX at once (one from its Client to the Server of another 
device and one from the Client of another device to its server). If one of these devices receives an 
incoming Tiny TP connection when it already has an outgoing Tiny TP connection then it may perform an 
IrLAP disconnect which will disconnect all Tiny TP/IrLMP connections. 


4.6.2 Discovering the Push Server 


The Push Client device must discover the Push Server device using the IrLMP discovery service 
described in [IrLMP]. If the Push Client device already has an IrLAP connection to a another device, then 
it is assumed that this other device is the Push Server. 


4.6.3. Establishing a Tiny TP Connection 


The Push Client must establish a Tiny TP connection to the Push Server using the Connect request 
procedure described in [TTP]. 


4.7 IAS Requirements 
The Push Server must have an JAS entry for a default OBEX server as described in [IrOBEX]. 


4.8 IrLAP Requirements 


There are no special issues concerning IrLAP. 


4.9 Physical Layer Requirements 


Devices are allowed to support the short-range option as described in [IrPHY]. 
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